How To Start Your Own Games Studio, Pt 2

At Introversion we loosely adhere to a spiral software engineering paradigm and I would recommend this approach for developing any prototype. Here’s how it works.

The first stage is to sit down and determine the scope of the project. Whether you are aiming to produce one complete level, a small area of your huge game world, or perhaps a large area with only some elements included – whatever it is, you need to understand and stay focused on achieving this objective.

When you’ve chosen the scope then you need to try to deal with the most uncertain part of your design. Which areas are you least confident in? Which areas are of most importance to the player? Where are the technical challenges? Asking yourself questions like these should help you determine what to include in your prototype and what to leave until later stages of development. Get the basics right first, lay the foundations and build upwards from there.

Once you have determined the scope I would recommend a quick first pass to get something playable as soon as possible. Try to avoid getting bogged down with low risk details. At this stage you should not be making the game look great or worrying about implementing your maps perfectly, just get something working in a rough frame of placeholder graphics and barely-adequate sounds.


Once you have completed your first very raw version of Your Awesome Game, you should then go back and give the whole thing a second pass. This is where you start to deal with the next layer of detail and finally (if there is time) you may want to do a final pass for polish – turning those placeholders into something more and making your framework more presentable.

The above approach provides a good deal of momentum for your initial work. It enables you to tackle the hard problems first and not get caught up in something that might ultimately prove impossible.

If you get stuck, try to solve the problem for a couple of days, and if you don’t make progress then just move onto the next problem and worry about it in the next phase. It’ll inform you about the quality of the game design and enable you to make massive global changes without having to go back and re-do all the detail.

This method has served us at Introversion very well in the past and if you have been reading Chris’s Subversion development blog then you’ll see that he is constantly switching between different aspects of the game whilst he improves his design.

I also mentioned that prototypes have an external (secondary) objective and that is to convince someone (a publisher, investor, government body etc.) to give you some money. If you find yourself in a position to use your prototype in this manner then you need to bear in mind one fact: The publisher will run your .exe once and once only.


If your game doesn’t work, game over. If it is not obvious what he needs to do, game over. If it crashes in the opening few minutes, then game over.

In short, don’t expect any slack whatsoever – because you will not get it.

This means you must test your prototype, fix the bugs, and make 100 percent sure it will run.

This sounds simple, but I once told a developer that I was off to see Microsoft and I would show them his prototype if he could get it to me. He sent me three e-mails, each with a different build (he kept fixing last minute bugs), and none of them worked. Sadly, that was his one chance for an XBLA deal gone out the window.

I’m not going to deal with testing in this article, because there are a ton of books out there on the subject, but I leave you with this thought: If Uplink had crashed when Kieron Gillen put it in his PC, where would Introversion be now?